For most private networks, some form of authentication is required before a client computer is allowed to access resources on the network. A client computer may be authenticated when the computer, or the user of the computer, provides authentication information, which may be based on one or more “factors.” A factor may be something possessed by the user, such as a smart card, or something known to the user, such as a password, or some attribute of the user, such as a fingerprint or eyelid reading. The number of these factors required for authentication may depend on the risk of improperly granting access or likelihood that a client computer is not authorized to access the network.
Authentication information may be based directly on one or more of these factors. In other instances, authentication information may be derived indirectly from one or more of these factors. A client computer may provide one or more of these factors to a source trusted by a network administrator, which may then issue a certificate, identifying a device as a valid client. The certificate, whether alone or with other factors, may authenticate the client computer. Regardless of how the information is obtained, it may be used as part of an exchange between the client computer and an access control mechanism such that the access control mechanism only grants access if the client can be authenticated.
Various mechanisms may be employed to enforce a determination of whether to grant or deny access to a client. Typically, following an authentication process, an authorization process is performed using the authentication information together with additional parameters to determine the access rights of the specific client. The specific mechanism for a network may depend on the implementation of the transport layer of the network. In general, once a client is authenticated, the transport layer will route messages to or from the client. For devices that are not authenticated, even if physically connected to the network, the transport layer does not pass messages to or from the device.
A second, heretofore unrelated, issue for network administrators is “client health enforcement.” In this context, “health” indicates a configuration of protective components of a device. Those components may be software tools, such as anti-virus software or a firewall. Alternatively, the protective components could be part of the operating system, such as a patch that remedies a vulnerability in a file management system or other operating system component. Configuration information that defines health of a component may include, in addition to data such as parameters of operation that have been set for the component, the operating status of the component, such as whether it is operational or disabled. Client computers without protective components or improperly configured or disabled protective components are at risk of being infected with computer viruses or otherwise subject to attack by malicious parties pose a risk to the network.
If a computer infected with a virus is given access to a network, the virus may readily spread over a network, particularly a private network. Private networks are generally configured to protect against attacks from outside the network. They are generally less equipped to guard against threats from devices on the network because it is presumed that all clients on the network can be trusted and a free flow of information among the trusted devices is desired. A device that, because of its poor health, is exposed to attack from outside parties can become a conduit for malicious parties to gain access throughout the private network. Accordingly, client devices in poor “health” may be excluded or given only limited access to a private network.
For these reasons, many private networks use some form of client health enforcement. As an example, MICROSOFT Corporation, of Redmond, Wash., USA, provides a health enforcement framework called Network Access Protection.™ In a network using this framework, even though a device may be authenticated to the network, the device is not initially allowed access, or is not allowed to continue with network access, unless it provides an acceptable statement of health to a health policy server.
The statement of health indicates the configuration of protective components on the client device. If that statement of health indicates the device is in compliance with network policies, the health policy server may indicate to the network access control mechanism that the device can be allowed access. On the other hand, if the statement of health is not in compliance with network policies, the health policy server may indicate to the network access control mechanism not to allow the device access. For devices denied access, the health policy server also may notify the device of the reasons why the client is not in compliance so that the client may remediate itself.